Admin-Benutzerhandbuch: Journey-Autorisierung

Was ist Journey-Autorisierung?

Bei der Journey-Autorisierung geht es nicht darum, dass sich Ihre Kunden anmelden. Es geht darum zu schützen, wie Ihre Journey aufgerufen und angezeigt wird.

Wenn Sie die Autorisierung für eine Custom Journey (mit einer Input-Komponente) aktivieren, stellen Sie sicher, dass die Journey nur über Ihre freigegebene Web-Schicht (den sogenannten Renderer) ausgeführt werden kann — dort, wo Ihre Business-Regeln, Personalisierungslogik und Compliance-Prüfungen angewendet werden.

Ohne Autorisierung könnte jemand versuchen, direkt auf die Journey zuzugreifen und diese Regeln zu umgehen. Das könnte:

• Falsche Inhalte anzeigen
• Rechtliche Prüfungen oder Offer-Validierungen überspringen
• Die beabsichtigte Customer Experience stören

Die Journey-Autorisierung verhindert das.

Warum ist das für Marketer wichtig?

Wenn Sie Journey-Autorisierung aktivieren, hilft Ihnen das dabei:

• Ihre Marke und Compliance zu schützen: Rechtliche Prüfungen, Eligibility-Regeln und Personalisierungslogik werden immer angewendet.

• Ein konsistentes Erlebnis sicherzustellen: Kunden können nicht auf unvollständige oder unbeabsichtigte Versionen Ihrer Journey zugreifen.

• Sicherheitslücken zu schließen: Einmal aktiviert, kann die Journey nicht mehr auf Wege aufgerufen werden, die Ihre konfigurierten Regeln umgehen.

Kurz gesagt: Ihre Journey läuft immer so, wie Sie sie entworfen haben.

Was passiert im Hintergrund?

Wenn die Autorisierung aktiviert ist:

• Die Journey wird an einen Renderer gepinnt (sichere Web-Schicht).
• Wenn jemand versucht, direkt auf die Journey zuzugreifen:
  • wird er automatisch über den sicheren Renderer umgeleitet, oder
  • der Zugriff wird verweigert.
• Normaler Customer-Traffic ist nicht betroffen.
• Nicht autorisierte Zugriffsversuche werden blockiert.

Für den Endnutzer ändert sich nichts — er sieht einfach das korrekte Erlebnis.

Journey-Autorisierung konfigurieren

Folgen Sie den Schritten unten, um die Autorisierung für eine Benutzerdefinierter Journey zu aktivieren.

1. Öffnen Sie in den Eigenschaften einer Benutzerdefinierter Journey mit Input-Komponente im linken Menü Advanced:

2. Aktivieren Sie die Option Require authorization for all online actions.

3. Klicken Sie anschließend im Custom Journey auf die Input Component, um die Eigenschaften zu öffnen, und sichern Sie den Anonymous Link, der nach dem Veröffentlichen der Journey verfügbar ist. Dieser Anonymous Link ist Ihr Zugangspunkt zu dieser Journey.

4. Sobald die Autorisierung für eine Journey aktiviert ist, müssen Sie ein Servicekonto vom Typ Rendering einrichten.

5. Gehen Sie zu Admin configuration/Access Mgmt und aktivieren Sie den Eintrag „Service account“.
Erstellen Sie ein neues Servicekonto vom Typ rendering.

6. Kopieren Sie nach dem Speichern Key und Secret zur späteren Verwendung.

Journey-Autorisierung anwenden, um Ihre Journeys zu schützen

Es gibt zwei Hauptszenarien, wenn Sie Journey-Autorisierung verwenden, um den Zugriff auf Journeys abzusichern:

• Verwendung des generischen Selligent Content Renderers
• Verwendung von Custom Web Apps oder anderen Selligent Anwendungen

Szenario 1: Journeys mit dem generischen Selligent Content Renderer absichern

Autorisierung auf Journey-Ebene erzwingt den sicheren Pfad

• Mit Autorisierung auf Journey-Ebene können diese Journeys nur über den sicheren Pfad geladen werden.
• Nur Nutzer von erlaubten IPs können auf den Journey-Content zugreifen.
• Die Verwendung des nicht-sicheren Links liefert einen Fehler, statt den Content zu laden.

Was das für Marketer bedeutet

• Nur freigegebene Umgebungen können Ihre Journey laden.
• Eine versehentliche Nutzung falscher Links führt nicht dazu, dass Content offengelegt wird.
• Die Sicherheit wird automatisch durchgesetzt.

Konfiguration des sicheren Content Renderers anpassen

Einführung

Eine Journey, die den generischen Selligent Content Renderer mit integriertem IP-Filtering nutzt (über die /secure/ URL — vgl. Https://your_domain/renderers/swagger/ui/index#/Content), kann durch Journey-Autorisierung zusätzlich abgesichert werden.

Da die Journey den IP-Filtering Content Renderer verwendet, enthält die CFG_CR_IPSEC-Tabelle bereits die notwendige IP-Filtering-Konfiguration für diese Journey.

Um den Renderer per Journey-Autorisierung an die Journey zu pinnen, müssen Sie nur den bestehenden Konfigurationseintrag der Journey um ein gültiges Rendering-Servicekonto erweitern.

Wie das genau geht, wird in den folgenden Schritten beschrieben.

Aktualisieren der Konfigurationstabelle des Content Renderers

Die CFG_CR_IPSEC-Tabelle wird verwendet, um sicheres Rendering für Journeys zu ermöglichen. Der Konfigurationseintrag enthält:

• Journey-ID(s)
• Freigegebene IP-Adressen
• Servicekonto-Key

Das Feld ‘SERVICEACCOUNT_KEY’ ist ein optionales Feld, mit dem festgelegt werden kann, welche Journey die oben erstellten Servicekonto-Credentials verwenden soll. Wenn Sie jedoch Content aus einer Journey laden möchten, für die „authenticate“ aktiviert ist, müssen Sie eine Konfiguration in dieser Tabelle hinzufügen:

Hinweis:
Um die Journey-ID der in Schritt 1 erstellten Journey zu ermitteln:
SELECT ID FROM CAMPAIGNS WITH(NOLOCK) WHERE NAME = '{YourJourneyName}' ORDER BY ID DESC
Verwenden Sie diese ID, um einen Datensatz in die CFG_CR_IPSEC-Tabelle einzufügen.
INSERT INTO CFG_CR_IPSEC(NAME, IPS, JMS, SERVICEACCOUNT_KEY)
VALUES('{YourConfigurationName}','{OneOrMore_Ips}', '{OneOrMoreJourneys}' , '{YourServiceAccountKEY_From_Step_2}')

Konfiguration des sicheren Content Renderers testen

Die Verwendung von Journey-Autorisierung stellt sicher, dass die Nutzung des Anonymous Links der Custom Journey ohne den /secure/ Pfad zu einem Fehler führt: 200 - kein Content. Wenn Sie den Anonymous Link mit dem ‘secure’ Pfad verwenden, erhalten Sie den tatsächlichen Content (es sei denn, Ihre IP ist nicht in der CFG_CR_IPSEC-Liste enthalten. Während dieser Prüfung protokolliert die Log-Datei die IP, wenn die Authentifizierung fehlschlägt).

Auf die Journey über den sicheren Renderer zugreifen (/secure/ Pfad)

Folgen Sie den Schritten unten, um sicherzustellen, dass die Zugriffseinstellungen wie erwartet funktionieren: Wenn Sie den sicheren Renderer verwenden, werden IP-Adressen gegen die Liste der freigegebenen IPs geprüft:

Öffnen Sie den sicheren Journey-Link über den sicheren Renderer-Link (z. B. über den API Explorer).

Erwartetes Ergebnis:

• für Requests von einer freigegebenen (whitelisteten) IP-Adresse => der Content lädt korrekt und Sie können den Journey-Content ohne Fehler anzeigen

• für Requests von einer nicht freigegebenen IP-Adresse (z. B. ein privates Netzwerk ohne VPN) => der Zugriff wird verweigert. Sie sehen eine Fehlermeldung oder erhalten ein “Access Denied”.

Versuchen, direkt auf die Journey zuzugreifen

Folgen Sie den Schritten unten, um sicherzustellen, dass der Renderer den Zugriff auf die Journey ohne Renderer unmöglich gemacht hat — das bedeutet, dass Zugriff von nicht whitelisteten IP-Adressen nicht mehr möglich ist:

Öffnen Sie den sicheren Journey-Link über die /content/default API (oder über einen direkten optiextension Link).

Erwartetes Ergebnis:

• Früher konnten Requests von nicht whitelisteten IPs, die über andere Wege als den sicheren Renderer auf den Content zugreifen, erfolgreich sein.

• Nachdem der Renderer an die Journey gepinnt wurde, werden Requests von nicht whitelisteten IPs, die über andere Wege als den sicheren Renderer auf den Content zugreifen, nun abgewiesen (Access Denied).

Journeys mit Custom Web Apps oder anderen Selligent Anwendungen absichern

Die Anwendung anpassen

Eine Anwendung, die Journey-Content verwendet, führt typischerweise folgende Schritte aus:

1. Business-Logik anwenden

2. Einen serverseitigen Call an den optiextension Endpoint ausführen (direkt oder über eine Library), um Content zu laden

3. Den geladenen Content in die App einbetten und dem Nutzer anzeigen

Um zu verhindern, dass die Business-Logik dieser Apps umgangen wird, „pinnen“ wir die Anwendung in Schritt 2 an die Journey, indem wir einen zusätzlichen Basic Authorization Header übergeben.

Format des Authorization Headers:

'Authorization: basic base64(<serviceaccount_key + ':' + <serviceaccount_secret>)'.

Beispiel: Für ein Servicekonto mit key = 'mykey' und secret = 'mysecret' wird der Header zu:
'Authorization: Basic bXlrZXk6bXlzZWNyZXQ='

WICHTIG:
Der Authorization Header darf NUR serverseitig zwischen der Anwendung und der optiextension hinzugefügt werden.
Geben Sie niemals weiter:
- Servicekonto-Key
- Servicekonto-Secret
Wenn diese Daten offengelegt werden, ist die Sicherheit kompromittiert.

Die Anwendung testen

Nach der Einrichtung:

• Zugriff auf die Journey über die Anwendung. Der erwartete Content lädt normal.

• Direkter Zugriff auf die Journey ohne Authorization Header. Der Request wird abgewiesen (Access Denied), da ein normaler Direkt-Request den richtigen Authorization Header nicht enthält.

Hinweis: Für Tests können Sie Postman, Bruno, Curl oder ein anderes HTTP-Client-Tool verwenden, um den Authorization Header in einen direkten Request an die optiextension einzufügen und zu prüfen, ob die Journey je nach Vorhandensein/Fehlen eines gültigen Authorization Headers korrekt abgesichert ist.

Hier ein Beispiel mit Postman.
1. Verwendung des Anonymous Links ohne Autorisierung führt zu folgendem Fehler:

2. Verwendung desselben Anonymous Links, aber mit Basic Autorisierung (Key und Secret aus dem Servicekonto) liefert den Content korrekt zurück: